The Mobile IP Working Group of the Internet Engineering Task Force (IETF) has developed routing support to permit IP nodes (hosts and routers) using either IPv4 or IPv6 to seamlessly “roam” among IP sub-networks and media types. The mobile IP method supports transparency above the IP layer, including the maintenance of active Transmission Control Protocol (TCP) connections and User Datagram Protocol (UDP) port bindings.
The Mobile IP Working Group is attempting to address deployment issues in Mobile IP and provide appropriate protocol solutions to address known deficiencies and shortcomings. For example, the wireless/cellular industry is considering using Mobile IP as one technique for IP mobility for wireless data. The Working Group is developing standards to deploy Mobile IP protocols in the wireless data context.
Internet Protocol Version 6 (IPv6) is the next generation IP protocol. Started in 1991, the specification was completed in 1997 by the IETF. IPv6 is backward compatible with, and is designed to fix the shortcomings of, its predecessor IPv4. Two notable shortcomings fixed by IPv6 relate to data security and the maximum number of user addresses. IPv6 increases the address space from 32 to 128 bits, providing for an unlimited (for all intents and purposes) number of networks and systems. It also supports quality of service (QoS) parameters for realtime audio and video. Originally called “IP Next Generation” (IPng), IPv6 is expected to slowly replace IPv4, with the two existing side by side for many years.
As originally specified, Mobile IP for IPv6 (Mobile IPv6) was presumed to work for mobile nodes that were themselves also routers. Thus, the mobile router would be the point of attachment to the Internet for a collection of subnets, which then could be populated with either fixed or mobile nodes. Passengers on a ship or on a train are examples of mobile nodes that might rely on a mobile router, but clearly many fixed nodes on the ship or train might also have the same reliance. Recent concerns about address ownership have undermined the previous confidence about whether the base protocol specifications are appropriate for mobile routers as well as mobile nodes.
The Network Mobility (NEMO) Working Group of the IETF is concerned with managing the mobility of an entire network, which changes, as a unit, its point of attachment to the Internet, and thus its reachability in the topology. The mobile network includes one or more mobile routers which connect it to the global Internet.
A mobile network is assumed to be a leaf network (it may be complex with many leaf networks embedded in it, so that the Mobile Router would carry traffic to and from those networks), i.e. it will not carry transit traffic. However, it could be multihomed, either with a single mobile router that has multiple attachments to the internet, or by using multiple mobile routers that attach the mobile network to the Internet. The NEMO Working Group's approach assumes that the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption will be made to accommodate nodes inside the network that are not generally aware of mobility.
A basic approach for network mobility support is for each mobile router to have a Home Agent (HA), and use bidirectional tunneling between the mobile router and HA to preserve session continuity while the mobile router moves. The mobile router will acquire a care-of address from its attachment point similar to what is done for mobile nodes using mobile IP. This approach allows nesting of mobile networks, since each mobile router will appear to its attachment point as a single node.
With reference to FIG. 1, a block diagram illustrates the structure of a network according to the NEMO Working Group's described system in which a mobile node 100 and a mobile router 120 are in their home wireless network environment connecting to the Internet 10. The mobile node 100 is at home on its home link with its home agent 110. A mobile router 120 is at its home wireless location. The mobile router 120 provides routing for an access link, on which there is a fixed node 130, and an access link for a fixed router 134.
The mobile router 120, a gateway to the Internet 12, and a home agent 14 are routers that forward packets. They each may also use same dynamic routing protocol. There is a correspondent node 102 for the mobile node 100, and a correspondent node 122 for the mobile router.
When a mobile node moves away from its home to link, it signals its home agent 110, and its correspondent node 102 to provide its location and router on which the mobile node 100 is a guest. Bindings are configured on the mobile node's home agent 110 and correspondent node to send and receive data traffic to and from the mobile node 100. Similarly, when mobile router 120 moves away from its home link, it similarly updates its home agent 14, and its correspondent node 122 regarding its new location.
In the NEMO Working Group's system, both mobile node 100 and the mobile router 120 use the NEMO protocol (RFC 3963) along with Mobile IPv6, except that there are further implications to the packet forwarding implementation of the mobile router 120 and home agent 14 for the mobile router 120. Specifically, the mobile router 120 and the home agent 14 for the mobile router use bidirectional tunnel to send and receive data between them. The mobile router 120 installs an encapsulation interface directed towards its home agent 14 when it detects that it is no longer within its home network. Through this interface the mobile router 120 forwards (reverse-tunnels) all packets not originated from the mobile router 120 towards its home agent 14. For packets originated from mobile router, the mobile router functions as if the it is a normal mobile node 100. The packets get forwarded on the visited link, except if the packets are targeted to the home link, then they get reverse-tunneled to home agent. Hence, when arriving at a visited link, the mobile router 120 injects a default route and a network route of its home link, towards the reverse tunnel it creates pointing to its home agent 14, in addition to a default route to the a default router used by the mobile router 120 on the visited link. If the mobile router 120, home agent 14, and gateway at the visited link were running a dynamic routing protocol, the mobile router 120 redirects control traffic of this protocol towards the home agent, tunneling these packets through the reverse tunnel pointing to home agent 14 for the mobile router 120. The dynamic routing protocol updates the routing state between the gateway at the visited location, the home agent 14 for the router, and the mobile router 120.
According to the NEMO Working Group system, if it is not desired that the mobile router 120 runs a dynamic routing protocol, the home agent 14 keeps persistent information regarding the mobile router and its mobile network prefix(es), and injects routing entries into its table based on Binding Updates from the mobile router 120.
There are some solutions being developed in conjunction with the NEMO Working Group that suggest assigning a prefix to a mobile router. An IETF draft for NEMO protocol, draft-droms-nemo-dhcpv6-pd-01.txt, “DHCPv6 Prefix Delegation for NEMO, by Ralph Droms and Pascal Thubert (Droms-Thubert) of Cisco describes the messaging format and protocol operations for transmitting one or more prefixes from a DHCPv6 server (or a home agent acting as a DHCPv6 Relay) to a Mobile Router. The approach described in Droms-Thubert uses a transformation on the lower 64 bits of a mobile network node's address in order to find the home address (HoA) of a mobile router. However, this, and other prior art approaches, have many shortcomings.
For the most part, one or more of the approaches in the prior art only show the protocol operations for “delegating” a prefix from a DHCPv6 server to a Mobile Router. Although some of the draft approaches use the word “delegation,” they do not describe a true delegation, in terms of authorization to use a prefix. DHCP is a Configuration protocol and, in general relies, on the concept of “return routability”—meaning that if a mobile node can receive packets on a link to which it is connected, it is more-or-less authorized to use an address on that link.
However, for an entire prefix, the same does not hold true. A router or entity that controls a superset of the prefixes assigned to the mobile router must explicitly allow the mobile router to use those prefixes, since the routing for the prefixes and all nodes contained there within can be manipulated and their traffic can be diverted, so the potential vulnerability to abuse is higher.
Accordingly, authorization must happen at, or at least be transmitted to, the home agent. Since the DHCPv6 server is likely to be a separate box on the network, the home agent has no way of determining whether the mobile router then using the prefix is actually allowed to do so (and hence change the routing characteristics of the prefix).
Finally, while the basic idea of using a prefix is referred to in the IETF NEMO signaling draft, there is insufficient detail regarding how the prefix is used. For example, there are no defined rules for how the home agent and mobile router process the signaling.